Private Branch Exchange (PBX) systems often used by enterprises provide important communication features such as voicemail, speed dial, call transfer, conference, directory services, and the like. Connection between a PBX switch and one or more PBX sets is usually accomplished via a non-standard, vendor-specific, private-digital-signaling-and-voice (PDSV) protocol. This protocol exposes the various communication features offered by the PBX switch to each PBX set. One drawback in the use of PDSV protocols is that they are vendor-specific, and thus, often typically incompatible between different vendors. Consequently, an enterprise must typically purchase both the PBX and the PBX sets from the same vendor.
In the last few years, PBX system architectures have evolved from providing a direct digital connection with the PBX sets to providing a networked IP connection. However, the lack of interoperability between an IP-PBX from one vendor and the IP sets from another vendor has continued. Thus, if a customer purchases an IP-PBX from one particular vendor, he is still generally forced to choose IP sets from the same vendor, even if he prefers the style, look, or feel of IP sets from another vendor.
Recently, a new standard referred to as a Session Initiation Protocol (SIP) for IP session control has emerged from the Internet community, as set forth in Internet Engineering Task Force Request for Comment 2543 entitled “SIP: Session Initiation Protocol,” March 1999 (hereinafter referred to as RFC 2543), which is incorporated herein by reference. The SIP protocol controls the setup, modification and teardown of general data exchange sessions, including Voice-over-IP (VoIP) sessions, between users on an IP network.
The emergence of the SIP protocol has given rise to a potential for an enterprise customer to purchase an IP-PBX manufactured by one vendor and SIP sets manufactured by other vendors. For example, an enterprise could potentially purchase an IP-PBX from one vendor based on the communication feature set and functionality included in the IP-PBX, and purchase SIP Sets having a preferred style or feel from another vendor. However, in order for this to occur, there exists a need to interface SIP sets to an IP-PBX that may not have native SIP support.